Method and system for providing telecommunication services across networks that use different protocols

ABSTRACT

A method and system provide seamless, wireless telecommunication service to customers that move between disparate networks that use different protocols. A Universal Location Service Register (ULSR) communicates and provides mobility management and authentication functions across networks that use different protocols. Instead of associating each MSC with an HLR and an AuC that uses the same messaging protocol as the MSC, each MSC communicates with the ULSR for user information. The ULSR communicates with the MSCs in each network serviced by the ULSR in accordance with the protocol of that network. The ULSR stores user profiles that may include the identity of the user, authentication information for the user&#39;s mobile phone, a list of networks the user is authorized to access, and the identity of the MSC at which the user is currently registered.

RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. ProvisionalApplication No. 60/141,110, filed on Jun. 24, 1999, and titled“Universal Location Service Register (ULSR),” the contents of which areincorporated by reference as if fully disclosed herein.

BACKGROUND OF THE INVENTION

[0002] 1. Field of the Invention

[0003] This invention relates generally to telecommunication services,and, more specifically to a system and method for providingtelecommunication services across networks that use different protocols.

[0004] 2. Description of Background Art

[0005] In many conventional telecommunication networks that providewireless telecommunication services, such as ANSI-41 and GSM networks,each mobile phone user is associated with a Mobile Switching Center(MSC) that is referred to as a user's “home MSC.” A mobile phone user'shome MSC receives all calls for the user and either (1) routes the callsto the user if the user is within the coverage area of the home MSC or(2) if the user is not within the coverage area of the home MSC, routesthe calls to the MSC at which the user is currently registered (the“serving MSC”), where the serving MSC then routes the calls to the user.

[0006] In conventional ANSI-41 and GSM networks, each MSC is associatedwith a Home Location Register (HLR), a Visitor Location Register (VLR)and an Authentication Center (AuC). The functions of an AuC includestoring authentication information for mobile phone users whose home MSCis the MSC associated with the AuC. The functions of an HLR includestoring profiles of users whose home MSC is the MSC associated with theHLR and, for each of such users, storing the identity of the MSC atwhich the user is currently registered. The functions of VLR includestoring users profiles of roaming users temporarily registered at theMSC associated with the VLR.

[0007] When a user roams out of the territory of his home MSC and intothe territory of a serving MSC, the VLR of the serving MSC (the “servingVLR”) needs to communicate with the HLR of the home MSC (the “home HLR”)in order to enable the user to register at the serving MSC and to enablethe home MSC to route calls for the user to the serving MSC. Forinstance, the serving VLR informs the home HLR that the user hasrequested registration at the serving MSC, and the home HLR sends theserving VLR user profile information. Additionally, when the home MSCreceives a call for the user, the serving VLR sends the routing numberof the serving MSC to the home HLR, which enables the home MSC to routethe call to the serving MSC.

[0008] Due to the variety of portable telecommunication devices, it isnot uncommon for customers to subscribe to telecommunication servicesthat are provided by multiple telecommunication networks. A customer maysubscribe to multiple telecommunication networks that each cover adistinct and separate service area or that have overlapping serviceareas, as is the case if a customer subscribes to a satellite basedsystem and an ANSI-41 based system both having broad service coverage inNorth America. In some cases the customer may use a device that iscapable of working in multiple networks, such as a dual mode mobilephone that supports two of the wireless air interface standards commonlyused in North America (e.g., PCS1900 and TDMA standards), or thecustomer may use multiple devices where each device operates in aspecific telecommunications network. Customers may require access totelecommunication services from one network at a time or from multiplenetworks simultaneously depending on their current geographic locationand the service coverage of the telecommunications networks to whichthey subscribe.

[0009] As indicated above, in order to provide seamless services tocustomers as they travel or switch between different networks, variousHLRs and VLRs in the different networks need to communicate with eachother. However, this can be problematic because many of thetelecommunication networks use different protocols for communicationsbetween the HLRs, VLRs, AuCs, and MSCs within their own networks. Forinstance, many North American networks use the ANSI-41 protocol and manyEuropean networks use the GSM protocol. Therefore, it is necessary toenable networks that use different protocols to communicate with eachother in order to provide seamless service to customers as they movebetween these networks.

[0010] There are known methods for enabling communication betweendisparate networks that use different protocols. One such method, whichis described in U.S. Pat. No. 5,862,481, provides an Inter-TechnologyRoaming Proxy (IP) that translates requests from one network to another.One problem with this method is that if a lot of networks are involved,a lot of additional equipment is required. For N networks, the number ofIPs required is N(N−1). For example, two networks require two (2) IPsand four networks require twelve (12) IPs. Additionally, this methodfails to provide a way to manage feature and service interactions when acustomer has simultaneously access to telecommunications services frommultiple networks.

[0011] Therefore, it is desirable to provide seamless services tocustomers as they roam into disparate networks without using as muchequipment as known methods for providing such services. Additionally, itis desirable to manage feature and service interactions for customersthat have simultaneous access to telecommunication services in multiplenetworks.

SUMMARY OF THE INVENTION

[0012] The present invention provides a method and system for providingseamless, wireless telecommunication services to customers that movebetween disparate networks. A Universal Location Service Register (ULSR)communicates and provides mobility management and authenticationfunctions across networks that use different protocols. Instead of eachMSC communicating with its own HLR and AuC to exchange user information,each MSC communicates with the ULSR to exchange such information,thereby eliminating the need for associating each MSC with its own HLRand AuC. The ULSR communicates with the MSCs in each network serviced bythe ULSR in accordance with the protocol of that network. The ULSR storeuser profiles that may include the identity of the user, authenticationinformation for the user's mobile phone, a list of networks the user isauthorized to access, and the identity of the MSC at which the user iscurrently registered.

[0013] When a user roams into a network other than the user's homenetwork and requests registration at an MSC in the such network (the“serving network”), the MSC (the “serving MSC”) notifies the ULSR thatthe user has requested registration. The ULSR determines whether theuser can be registered at the serving MSC, and, if so, authorizes theregistration. When a call is received for the user at an MSC in theuser's home network, the home MSC sends a request for the routing numberto the ULSR. The ULSR retrieves the user's profile and determines thatthe user is registered at the serving MSC. The ULSR sends a request fora routing number to the serving MSC, and the serving MSC provides theULSR with a routing number. The ULSR then sends the routing number tothe home MSC, and the home MSC routes the call to the serving MSC, whichroutes the call to the user. The ULSR communicates with the home networkin accordance with the protocol used by the home network, and the ULSRcommunicates with the serving network in accordance with the protocolused by the serving network.

[0014] In one embodiment, the ULSR also manages feature and serviceinteractions for customers. For instance, the ULSR may determine, basedon the user's profile, whether a user is subscribed to call waiting orcall forwarding service and then instruct the applicable MSCaccordingly. In yet another embodiment, if a user is simultaneouslyregistered in multiple networks, the ULSR will use information stored inthe user's profile and/or internal logic to determine to which network acall for the user should be forwarded.

[0015] Therefore, the present invention provides seamless service towireless device users as they roam across multiple networks whilereducing the amount of equipment used by known methods. Additionally,according to one embodiment, the present invention manages feature andservice interactions for users that have simultaneous access totelecommunication services in multiple networks.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016]FIG. 1 illustrates a ULSR coupled to multiple telecommunicationsnetworks in accordance with one embodiment of the present invention.

[0017]FIGS. 2a-c illustrate a method according to one embodiment of thepresent invention for registering a mobile phone user in network A,where the mobile phone user was previously registered in network B.

[0018]FIGS. 3a-b illustrate a method according to one embodiment of thepresent invention for registering a mobile phone user in an ANSI-41network, where the user was previously registered in a GSM network.

[0019]FIGS. 4a-c illustrate a method according to one embodiment of thepresent invention for registering a mobile phone user in a GSM network,where the user was previously registered in an ANSI-41 network.

[0020]FIGS. 5a-5 c illustrate a method according to one embodiment ofthe present invention for routing a call to a mobile phone user who hasa home network but is currently registered in another network.

[0021]FIGS. 6a-6 c illustrate a method according to one embodiment ofthe present invention for routing a call to a mobile phone user who hasan ANSI-41 home network, but is currently registered in a GSM network.

[0022]FIGS. 7a-7 c illustrate a method according to one embodiment ofthe present invention for routing a call to a mobile phone usersimultaneously registered in both a serving ANSI-41 network and aserving GSM network.

[0023]FIG. 8 illustrates an internal architecture for the ULSR accordingto one embodiment of the present invention.

[0024]FIG. 9 illustrates an example, according to one embodiment of thepresent invention, of how the internal architecture works to process aLocationRequest message from an ANSI-41 MSC.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0025]FIG. 1 illustrates a Universal Location Service Register (ULSR)1000 in accordance with the present invention. The ULSR 1000 cancommunicate and provide mobility management and authentication functionsacross telecommunication networks 1100 that use different protocols.(e.g., ANSI-41 networks and GSM networks). As will be discussed below,in one embodiment, the ULSR 1000 is also capable of managing feature andservice interactions for instances when a subscriber has access tomultiple networks 1100.

[0026] Because the ULSR 1000 is capable of communicating independentlyand simultaneously with networks that use different signaling standards,seamless service can be provided to a mobile phone user who roams into anetwork using a different protocol than his home network. The ULSR 1000can receive a message from one network and respond to that message, evenif processing the message involves sending a message to and receiving amessage from another network that uses a different signaling protocol.For instance, a LocationRequest message received by the ULSR 1000 froman ANSI-41 network may result in the ULSR 1000 sending a Provide RoamingNumber message to a GSM network if the ULSR 1000 knows that thesubscriber is in the GSM network when the LocationRequest message isreceived. When the ULSR 1000 receives a response from the GSM network toits Provide_Roaming_Number request, the ULSR 1000 uses the informationin the response to reply to the ANSI-41 network's LocationRequestmessage.

[0027] The ULSR 1000 has access to a database 1200 that storesinformation about subscribers to the networks 1100 serviced by ULSR1000, where the information in the database 1200 enables the ULSR 1000to provide mobility management and authentication functions for all thenetworks 1100 that the ULSR 1000 supports. Such information may includethe location at which the user is currently registered, the user's homenetwork, a list of networks to which a user is authorized to access, anddata for authenticating the user. Some of the information in thedatabase 1200 may be specific to one network, and other information maybe used to provide mobility and authentication functions for multiplenetworks. When a specific network needs information from the database1200, the ULSR 1000 encodes the information in accordance with theformat and protocol required by that network.

[0028]FIGS. 2a-2 c illustrate a method according to one embodiment ofthe present invention for registering a mobile phone in a network A(which may be a GSM, ANSI-41, or other network), where the mobile phonewas previously registered in a network B (which may be a GSM, ANSI-41,or other network). The registration procedure begins when the roamingmobile phone in the territory of network A realizes it can no longercommunicate with network B. When this happens, the roaming terminalrequests 205 registration from an MSC 2300 in network A and sendsinformation identifying itself (e.g., Mobile Serial Number (MIN),Electronic Serial Number (ESN), or International Mobile SubscriberIdentity (IMSI)) to the MSC 2300 in network A. The MSC 2300 in network Anotifies 210 the ULSR 1000 that the mobile phone has requestedregistration in network A and sends the ULSR 1000 informationidentifying the mobile phone. In response to receiving this message fromthe MSC 2300 in network A, the ULSR 1000 retrieves 215 from its database1200 the user profile associated with mobile phone and determines 220whether the mobile phone can be registered in network A. If so, the ULSR1000 updates 225 the database 1200 to reflect that the mobile phone iscurrently registered at the MSC 2300 in network A, and the ULSR 1000sends a message to the MSC 2300 in network A authorizing 230 suchregistration. The ULSR 1000 also sends 230 the user's profile to the MSC2300 in network A. If the mobile phone cannot be registered in networkA, the ULSR responds to the registration request by sending 222 the MSC2300 in network A a message indicating that registration is notauthorized. The ULSR 1000 and network A communicate with each other inaccordance with the protocol of network A.

[0029] The ULSR 1000 also determines 235 whether the user can besimultaneously registered in both networks A and B. If so, the processis complete. If not, the ULSR 1000 sends 240 a message to the MSC 2400in network B at which the mobile phone was previously registered,canceling the registration of the mobile phone in network B. The ULSR1000 and network B communicate with each other in accordance with theprotocol of network B.

[0030]FIGS. 3a and 3 b illustrate an example of using the methoddiscussed with respect to FIG. 2 for registering a mobile phone user inan ANSI-41 network 3050, where the user was previously registered in aGSM network 3150. Note that the MIN and ESN parameters, as well as theRegistrationNotification (REGNOT), registrationnotification (regnot),RegistrationCancellation (REGCAN), registrationcancellation (regcan),LocationRequest (LOCREQ), and locationrequest (locreq) messages,discussed herein are defined by the ANSI-41 protocol. Similarly, theIMSI parameter and the CANCEL_LOCATION, cancel_location,LOCATION_UPDATE, location update, INSERT_SUBSCRIBER_DATA,insert_subscriber_data, SEND PARAMETER, send parameter,PROVIDE_ROAMING_NUMBER, and provide_roaming_number messages discussedherein are defined by the GSM protocol. Note also that the names oracronyms for some messages are in upper case letters and some are inlower case letters. In accordance with the ANSI and GSM semantics, amessage in lower case letters is a response to a message in upper caseletters with the same name.

[0031] The registration procedure begins when the roaming mobile phonerealizes it can no longer communicate with the GSM network 3150. Whenthis happens, the roaming terminal requests 305 registration from theANSI-41 network 3050 and uses its MIN and ESN information to identifyitself. The MSC 3100 in the ANSI-41 network receiving the registrationrequest (the “ANSI-41 MSC”) sends 310 an ANSI-41RegistrationNotification (REGNOT) message to the ULSR 1000, where theREGNOT message indicates the registration request and includes the MINand ESN information that identifies the mobile phone. The ULSR 1000retrieves 315 the user profile associated with the mobile phone fromdatabase 1200 and determines 320 from the user profile whether the usercan be registered in the ANSI-41 network 3050. If the user cannot beregistered in the ANSI-41 network 3050, the ULSR sends 323 the ANSI-41MSC 3100 a message indicating that registration is not authorized. Ifthe user can be registered in an ANSI-41 network, the ULSR 1000 updates325 the database 1200 to indicate that the user is currently registeredand located at the ANSI-41 MSC 3100.

[0032] The ULSR 1000 also determines 330 from the user profile whetherthe user can be simultaneously registered in both the ANSI-41 and GSMnetworks 3100, 3150. If the user can be registered in only one of thenetworks at a time, the ULSR 1000 sends 335 a CANCEL_LOCATION message tothe MSC 3200 in the GSM network 3150 at which the user was previouslyregistered, indicating that the user is no longer registered at the GSMMSC 3200. In response to receiving the CANCEL_LOCATION message, the GSMMSC 3200 removes 340 the user profile from its records of registeredusers and acknowledges 340 receipt of the CANCEL_LOCATION message bysending a cancel_location acknowledgment message.

[0033] The ULSR 1000 also sends 345 a registrationnotification (regnot)message to the ANSI-41 MSC 3100, where the regnot message includes thecustomer's profile and authorizes the user's registration at the ANSI-41MSC 3100. The ULSR 1000 communicates with the ANSI-41 network 3050 inaccordance with standard ANSI-41 protocols and with the GSM network 3150in accordance with standard GSM protocols.

[0034]FIGS. 4a-4 c illustrate an example of using the method describedwith respect to FIG. 2 for registering a mobile phone user in a GSMnetwork 4150, where the user was previously registered in an ANSI-41network 4050. The registration procedure begins when the roaming mobilephone realizes that it can no longer communicate with the ANSI-41network 4050. When this happens, the roaming terminal requestsregistration from the GSM network 4150 and uses its IMSI to identifyitself. The MSC 4200 in the GSM network 4150 receives 402 theregistration request from the mobile phone and sends 403 aSEND_PARAMETERS message to the ULSR 1000, where the SEND_PARAMETERSmessage asks the ULSR 1000 for information needed by the GSM MSC toauthenticate the roaming mobile phone. The ULSR 1000 sends 404 the GSMMSC the requested information in the form of a send parameter message.If the GSM MSC 4200 is able to authenticate the mobile phone, it sends405 a LOCATION_UPDATE message to the ULSR 1000, where theLOCATION_UPDATE message indicates the registration request and includesthe IMSI information that identifies the mobile phone. The ULSR 1000retrieves 406 the user profile associated with the mobile phone from itsdatabase 1200 and determines 408 from the user profile whether the usercan be registered in the GSM network 4150. If the user cannot beregistered in the GSM network 4150, the ULSR 1000 sends 409 the GSM MSCa message indicating that registration is not authorized. If the usercan be registered in the GSM network 4150, the ULSR 1000 updates 410database 1200 to indicate that the user is currently registered at theGSM MSC 4200 and sends 412 the GSM MSC 4200 an INSERT_SUBSCRIBER_DATAmessage that authorizes the user's registration at the GSM MSC 4200 andincludes the user's profile.

[0035] The ULSR 1000 also determines 414 from the user's profile whetherthe user can be registered in both the ANSI-41 and GSM networks 4050,4150. If the user can be registered in only one network, the ULSR 1000sends 416 a RegistrationCancellation (REGCAN) message to the ANSI-41 MSC4100 to cancel the user's mobile phone registration at the ANSI-41 MSC4100. In response to receiving the REGCAN message, the ANSI-41 MSC 4100removes 418 the user's profile from its records of registered users, andsends 418 the ULSR 1000 a regcan message acknowledging that the user'smobile phone is no longer registered with the ANSI-41 MSC 4100.

[0036] After the GSM MSC 4200 successfully receives theINSERT_SUBCRIBER_DATA message with the user profile, it sends 420 theULSR 1000 a response insert_subscriber_data message acknowledging thatthe GSM MSC 4200 successfully received the requested information. TheULSR 1000 then sends 422 the GSM MSC 4200 a location_update messageconfirming the user's registration at the GSM MSC 4200 and indication asuccessful completion to the registration process.

[0037]FIGS. 5a-5 c illustrate a method according to one embodiment ofthe present invention for routing a call to a mobile phone user who hasa home network 5050 but is currently registered in another network 5150(the “serving network”). A call for the user is received 505 at theuser's home MSC 5100 in the home network 5050 (the “home MSC”). The homeMSC 5100 determines 510 that the user's mobile phone is currently notregistered at the home MSC 5100, and sends 515 a request to the ULSR1000 for a number to which to route the call, where the request includesthe identity of the mobile phone. The ULSR 1000 retrieves the userprofile associated with the mobile phone and determines 520 from theprofile that the user's mobile phone is currently registered at an MSC5200 in the serving network 5150 (“the serving MSC”). The ULSR 1000 thensends 525 a request to the serving MSC 5200 for a routing number, andthe serving MSC 5200 sends 530 the ULSR 1000 a routing number associatedwith the serving MSC 5200. The ULSR 1000 then forwards 535 the routingnumber to the home MSC 5100, and the home MSC 5100 routes 540 the callto the serving MSC 5200. The ULSR 1000 uses the protocol of the homenetwork 5050 to communicate with the home MSC 5100 and uses the protocolof the serving network 5150 to communicate with the serving MSC 5200.

[0038]FIGS. 6a-6 c illustrate an example of using the method describedwith respect to FIGS. 5a-5 c for routing a call to a user who has anANSI-41 home network 6050 but is currently registered in a GSM network6150. The in-bound call for the user is received 605 at the user's homeMSC 6100 in the ANSI-41 network 6050. The ANSI-41 MSC 6100 determinesthat the user's mobile phone is not currently registered at the ANSI-41MSC 6100 and, therefore, sends 610 a LocationRequest message to the ULSR1000 to obtain a routing number that can be used to route the incomingcall to the mobile phone user. In response to receiving theLocationRequest message, the ULSR 1000 retrieves 615 the user's profilefrom its database 1200. The ULSR 1000 determines 620 from the user'sprofile that the mobile phone user is registered at an MSC 6200 in theGSM network 6150 and sends 625 a PROVIDE_ROAMING_NUMBER message (whichis a standard GSM message to request a number to which to route a call)to the MSC 6200 in the GSM network 6150 at which the mobile phone useris registered. The GSM MSC 6200 provides 630 the ULSR 1000 with one ofits routing numbers in a provide_roaming_number message. The ULSR 1000then responds 635 to the ANSI-41 MSC 6100 with a locationrequest messagethat contains the routing number, and the ANSI-41 MSC 6100 routes 640the call to the GSM MSC 6200 for the user.

[0039] In one embodiment, the ULSR 1000 can also manage servicesprovided to customers in multiple communication networks. Examples ofsuch services are call screening and number translation. In an alternateembodiment, such services are provided by another system (and not theULSR 1000) accessible to multiple networks, where such services areprovided using methods similar to those described herein.

[0040] In one embodiment, the ULSR 1000 enables customers to beregistered simultaneously in multiple networks. In this embodiment, theULSR 1000 manages the interaction of services between networks for eachsubscriber. FIGS. 7a-7 c illustrate an example a method according to oneembodiment of the present invention for routing a call to a mobile phoneuser simultaneously registered in both a serving ANSI-41 network 7200and a serving GSM network 7300. In this example, a call is received forthe mobile phone user at the user's home ANSI-41 MSC 7100 and routed toa serving GSM MSC 7200, but this method also applies if a call isreceived at a user's home GSM MSC and routed to either a servicingANSI-41 MSC or a servicing GSM MSC.

[0041] The home ANSI-41 MSC 7100 receives 705 a call for the mobilephone user and determines whether the user's mobile phone is within itsservicing area (i.e., the home ANSI-41 MSC 7100 determines whether themobile phone is currently registered at the home ANSI-41 MSC 7100). Inresponse to determining 710 that the user's mobile phone is not in itsservicing area, the home ANSI-41 MSC 7100 sends 715 a LocationRequestmessage to the ULSR 1000 in order to obtain a number to which to routethe call (note that if a home GSM MSC had received the call, aLOCATION_UPDATE message would be sent). The ULSR 1000 checks itsdatabase and determines 720 that the user is currently registered atboth a GSM MSC 7200 and an ANSI-41 MSC 7300. Using information in theuser's profile (which is stored in the ULSR's 1000 database 1200), theULSR 1000 then determines 725 in which network in the coverage area inwhich the user is currently registered the user prefers to receivecalls. In this example, the ULSR 1000 determines that the preferrednetwork is the GSM network 7150 and, consequently, requests 730 arouting number from the GSM MSC 7200 in a PROVIDE_ROAMING_NUMBERmessage. The GSM MSC 7200 sends the ULSR 1000 a routing number in aprovide_roaming_number message, and the ULSR 1000 forwards 735 therouting number to the home ANS1-41 MSC 7100 in a locationrequestmessage. The home ANSI-41 MSC 7100 then routes 740 the call to the GSMMSC 7200.

[0042]FIG. 8 illustrates the internal architecture of the ULSR 1000according to one embodiment of the present invention. The ULSR 1000includes a network services software module 830, a message handlersoftware module 820, and a network discriminator software module 810. Inone embodiment, these modules 810, 820, and 830 are programmed in the‘C’ programming language and run on Compaq Computer Corporation'sHimilaya hardware with the NSK operating system and Compaq's IntelligentNetwork Server middleware software, but those skilled in the art willappreciate that the ULSR can be implemented using other software andhardware. The ULSR 1000 also includes appropriate interfaces (not shown)between the modules 810, 820, and 830, as well as an interface (notshown) to database 1200. The ULSR 1000 may also include interfaces forprovisioning operations and maintenance of the platform.

[0043] The network discriminator 810 serves as an interface to anynetwork elements that communicate with the ULSR 1000. For each messagereceived at the ULSR 1000, the network discriminator 810 determines thetype of network (e.g., ANSI-41, GSM, etc.) from which the message wassent based on the message format.

[0044] Once the network type is identified, the network discriminatormodule 810 sends the message to a message handler 820. There is at leastone message handler 820 for each type of network that the ULSR 1000supports (where message handlers 820 can be added as the ULSR 1000 isrequired to support new network types), and the network discriminatormodule 810 sends the message to the message handler 820 for the type ofnetwork from which the message was sent. Such message handler 820identifies the type of message received from the operation code withinthe message or other applicable part of the message. For instance, anANSI-41 message handler 820 identifies an ANSI-41RegistrationNotification message by the operation code 0×0, which is theoperation code assigned to the RegistrationNotification message per theANSI-41 Standard. Likewise, a GSM message handler 820 identifies a GSMUPDATE_LOCATION message from its operation code of 0×11 (per the GSMStandard). In one embodiment, the format of the operation code is theformat defined in the Transaction Capability Application Part (TCAP)protocol.

[0045] After a message handler 820 identifies the type of message, itdecodes the message and stores the substantive content of it in aconventional memory (not shown) in the ULSR 1000. The message handler820 then initiates a network service object 835, which is a subcomponentof the network services module 830. The message handlers 820 normalizeall information that they pass to network services objects 835 so thatsuch information does not include any formatting specific to aparticular network.

[0046] The network services module 830 includes multiple network serviceobjects 835, where each object 835 performs one or more tasks requiredto process messages received from the message handlers. For everypossible message that a message handler 820 can receive from a specifictype of network, there is a network service object 835 that will beinitiated by the message handler 820 to perform the function(s) requiredby the message. Because the network service objects 835 receivenormalized messages from the message handlers 820, they can each performone or more functions for more than one type of network. In oneembodiment, each network service object 835 performs a function for morethan one network, whereas in an alternate embodiment, one or morenetwork service objects 835 perform a function associated with aspecific network.

[0047] Network service objects 835 can access and update the ULSRdatabase 1200 as well as invoke other network service objects 835 aspart of their normal execution. Additionally, network service objects835 may initiate the transmission of a message to network elements inresponse to receiving a message from a network or for other reasons,such as changes to customer information stored in the ULSR database 1200that require a message to be sent to one or more networks (e.g., aQualificationDirective message in an ANSI-41 network). Messagesinitiated by network service objects 835 are not formatted for aparticular type of network, and, therefore, the message handlers 820 areresponsible for properly formatting messages initiated by networkservice objects 835. The network discriminator 810 is responsible forsending the formatted messages to the appropriate networks.

[0048]FIG. 8 illustrates some examples of various types of networkservice objects 835, but in no way does FIG. 8 illustrate a complete setof the types of network services objects. In one embodiment, theRegister Network object executes the logic required to process messagesreceived by the ULSR for devices attempting to register in a network(e.g., a RegistrationNotification message received from an ANSI-41network). The CallTermination object processes messages received whencalls are made to users subscribing to one of the networks supported bythe ULSR. For instance, if the MSC receiving the incoming call is in anANSI-41 network, then a Location Request message is received by the ULSRand executed by the Call Termination Network. The Authentication objectdetermines whether a user is authorized to register at a particularnetwork. The Get Routing Number object obtains a routing number for anMSC. For instance, during the processing of a call for a user, the CallTermination object may request a routing number from the Get RoutingNumber object, in which case the Get Routing Number object would managethe generation of messaging to request a routing number from the MSC atwhich the user is registered. The Cancel Registration object performsthe necessary updates to the ULSR database 1200 and manages themessaging to cancel the registration of a user at a particular MSC. TheUpdate Profile object manages the generation of messaging indicatingthat a registered user's profile has been updated. The network serviceobject 835 described herein are examples of one embodiment, and thoseskilled in the art will appreciate that the types of network serviceobjects 835 in the ULSR 1000 and their functions may vary.

[0049]FIG. 9 illustrates an example of how the network discriminator810, message handlers 820, and network services objects 835 work toprocess a call received at an ANSI-41 MSC for a user who is currentlyregistered and able to receive a call in a GSM network. When the homeANSI-41 MSC receives the call and realizes that the user is registeredelsewhere, it sends a LocationRequest messaged to the ULSR 1000 in orderto get a routing number for the MSC at which the user is currentlyregistered. The LocationRequest message is received by the networkdiscriminator 810, which identifies the message as an ANSI-41 message.The message discriminator 810 then invokes the ANSI-41 message handler820, which identifies the message as a LocationRequest message,normalizes the LocationRequest message and user information to removenetwork-specific dependencies, and invokes the appropriate networkservices object 835 with the normalized information.

[0050] The network services object 835 then processes the request. Aspart of its logic, it will look up the current state of the user in theULSR database 1200 to determine whether a user is registered at any MSC.If the user is registered at an MSC, the network services object 835sends a generic (i.e., not formatted for a particular network servicedby the ULSR 1000) request for a routing number to the message handler820 associated with the network in which the user is registered. In thisexample, the user's record indicates that the user is currentlyregistered at a particular GSM MSC. Consequently, the network servicesobject 835 sends a generic message requesting a routing number for suchGSM MSC to the GSM message handler 820.

[0051] The GSM message handler 820 then formats the message into a GSMPROVIDE_ROAMING_NUMBER message, and the network discriminator 810 sendsthe PROVIDE_ROAMING_NUMBER message to the GSM MSC at which the user isregistered. The GSM MSC replies to the ULSR 1000 with a routing numberin the form of a provide_roaming_number message. The reply is receivedat the network discriminator 810, which determines that the reply comesfrom a GSM network, and, therefore, the reply is sent to a GSM messagehandler 820, which decodes the reply and sends the substantive contentof the reply (e.g., the roaming number) in a generic, non-networkdependent form to the appropriate network services object 835. Thenetwork service object 835 analyzes the reply for a routing number forthe GSM MSC and sends to the ANSI-41 message handler 820 a response thatincludes the routing number. The ANSI-41 message handler 820 formats alocationrequest message (which includes the routing number), and thenetwork discriminator 810 sends it to the gateway ANSI-41 MSC thatoriginally handled the call.

[0052] The present invention has been described in the context of amobile phone network, but it could also be used to provide services forother wireless devices, such as pagers or portable computers forexample. Moreover, although the present invention has been describedabove in terms of specific embodiments, it is anticipated thatalterations and modifications thereof will no doubt become apparent tothose skilled in the art. It is therefore intended that the followingclaims be interpreted as covering all such alternatives andmodifications as falling within the true spirit and scope of theinvention.

We claim:
 1. A mobile communications method that comprises: receiving amessage from a wireless communication network (“serving network”)indicating that a mobile communication device user has requestedregistration at the serving network; storing in a database an indicationthat the mobile communication device user is registered in the servingnetwork; determining whether the mobile communication device user shouldbe registered in only one network; and in response to determining thatthe mobile communication device user should be registered in only onenetwork, sending a message to a wireless communication network where themobile communication device user was previously registered (“previousnetwork”) that the mobile communication device user is no longerregistered at the previous network.
 2. The method of claim 1, furthercomprising: receiving a routing number request message from a homewireless communications network (“home network”); retrieving from thedatabase an indication that the mobile communication device user isregistered in the serving network; sending a routing number request tothe serving network in accordance with a serving network protocol;receiving from the serving network a routing number; and sending therouting number to the home network in accordance with a home networkprotocol.
 3. The method of claim 2, wherein the home network protocol isdifferent than the serving network protocol, and wherein the methodfurther comprises: translating a routing number message from the servingnetwork protocol to the home network protocol.
 4. A mobilecommunications provision method in a mobile communications system havingat least two wireless networks with different mobile switching center(“MSC”) communication protocols, the MSCs in each wireless network beingcoupled to a universal location service register (ULSR) having adatabase of information about all subscribers registered in one or moreof the wireless networks, wherein the method comprises: tracking foreach registered subscriber in the database at least one MSC where thatregistered subscriber is registered (“a serving MSC”); receiving arouting number request associated with a registered subscriber; andproviding a routing number in response to the routing number request. 5.The method of claim 4, wherein said providing a routing number includes:determining a serving MSC for the registered subscriber associated withthe routing number request; sending a routing number request to theserving MSC; and receiving a routing number from the serving MSC.
 6. Themethod of claim 5, wherein said determining a serving MSC includes:selecting a serving MSC from a plurality of serving MSCs where theregistered subscriber is simultaneously registered.
 7. The method ofclaim 6, wherein said selecting includes: determining a preferredserving MSC from a user profile associated with the registeredsubscriber.
 8. The method of claim 5, wherein said sending a routingnumber request includes: translating the routing number request into aMSC communications protocol associated with the serving MSC.
 9. A mobilecommunications provision method in a mobile communications system havingat least two wireless networks with different mobile switching center(“MSC”) communication protocols, the MSCs in each wireless network beingcoupled to a universal location service register (ULSR) having adatabase of information about all subscribers registered in one or moreof the wireless networks, wherein the method comprises: receiving from aMSC a registration request associated with a subscriber; retrieving auser profile for the subscriber; refusing the registration request ifthe user profile indicates that the subscriber is not authorized toregister with the MSC; and sending the user profile to the MSC if theuser profile indicates that the subscriber is authorized to registerwith the MSC.
 10. The method of claim 9, further comprising: if the userprofile indicates that the subscriber is authorized to register with theMSC, updating the database to indicate that the subscriber is registeredwith the MSC.
 11. The method of claim 9, further comprising: determiningwhether the subscriber can be concurrently registered in multiplenetworks; and issuing a registration cancellation to any other MSCswhere the subscriber is registered if the subscriber cannot beconcurrently registered in multiple networks.
 12. A mobilecommunications system that comprises: a set of wireless networks eachhaving at least one mobile switching center (“MSC”), wherein at leastone wireless network in the set employs a MSC communication protocolthat differs from a MSC communication protocol employed by at least oneother wireless network in the set; a universal location service register(“ULSR”) coupled to the MSCs in each wireless network of the set, theULSR including: a database of information about all subscribersregistered in one or more of the wireless networks in the set.
 13. Thesystem of claim 12, wherein the ULSR is configured to track for eachsaid subscriber at least one MSC where that subscriber is registered (“aserving MSC”).
 14. The system of claim 13, wherein the ULSR is furtherconfigured to: receive a routing number request associated with asubscriber; determine a serving MSC for the subscriber associated withthe routing number request; send a routing number request to the servingMSC; receive a routing number from the serving MSC; and provide therouting number in response to the original routing number request. 15.The system of claim 14, wherein as part of determining a serving MSC,the ULSR is configured to select a serving MSC from a plurality ofserving MSCs where the registered subscriber is concurrently registered.16. The system of claim 14, wherein the ULSR is further configured totranslate the routing number request between different MSC communicationprotocols.
 17. The system of claim 12, wherein the ULSR is configuredto: receive from a MSC a registration request associated with asubscriber; retrieve a user profile for the subscriber; refuse theregistration request if the user profile indicates that the subscriberis not authorized to register with the requesting MSC; and send the userprofile to the requesting MSC if the user profile indicates that thesubscriber is authorized to register with the requesting MSC.
 18. Thesystem of claim 17, wherein the ULSR is further configured to update thedatabase to indicate that the subscriber is registered with therequesting MSC.
 19. The system of claim 17, wherein the ULSR is furtherconfigured to: determine whether the subscriber can be concurrentlyregistered in multiple networks; and issue a registration cancellationto any MSCs (other than the requesting MSC) where the subscriber isregistered if the subscriber cannot be concurrently registered inmultiple networks.